Cream of the Crop 20/Cream of the Crop 20 (Terry Blount) (1996).iso/program/javnl007.zip/JAVNL007.TXT

Text File | 1996-07-12 | 12KB | 358 lines

Issue #007
July, 1996


Contents:

Invoking Subprograms in Java
Comparing C/C++ to Java Part 7 - Destructors vs. Finalize
Free Java Library
Enums and Java
Introduction to Applet Programming Part 3 - Events


INVOKING SUBPROGRAMS IN JAVA

It's often the case that when writing programs, you'd like to invoke
another program from within the first and send it input and get output
from it.  How might this be done in Java?  A simple example that runs
the UNIX program "ls" to retrieve a listing of files in the current
directory looks like this:

        import java.io.*;

        public class test1 {

                public static void main(String args[])
                {
                        try {
                                Process cp = Runtime.getRuntime().exec("ls");
                                DataInputStream d =
                                    new DataInputStream(cp.getInputStream());
                                String line = null;
                                while ((line = d.readLine()) != null)
                                        System.out.println(line);
                        }
                        catch (Throwable e) {
                        }
                }

        }

The call to exec() starts the process running, and returns a Process
object.  Then we query the Process object to get a buffered input
stream that is connected to the output of the child process.  We then
can simply iterate over this stream, reading lines in turn, that are
the output of ls.  In a similar way, it's possible to send input to
the child process or capture its error output.

The Process class has several additional methods available for
controlling processes:

        waitFor()       wait for the child process to complete

        exitValue()     return the exit value for the process

        destroy()       kill the process

There is also a variant of exec() that supports passing of environment
variables to the child process.


COMPARING C/C++ TO JAVA PART 7 - DESTRUCTORS VS. FINALIZE

In C++ there is the notion of a destructor, a function called when a
class object instance goes out of scope.  For example:

        class A {
        public:
                A();
                ~A();
        };

        void f()
        {
                A a;
        }

When the function f() is entered, the constructor A::A() is called for
the local object a, and when f() is exited, the destructor A::~A() is
called in turn.

Java class objects do not behave in a similar way.  They are
dynamically allocated, at which point a constructor is run on the
object instance, and later garbage collected.

Java does not have any notion of a destructor method that is run when
an object instance is no longer valid.  But it does have a finalize()
method:

        protected void finalize() {}

that can be added to any class.  finalize() is called for an object
instance after that instance has been identified by the garbage
collector as no longer a valid object, that is, there are no remaining
references to it.  For example:

        public class test1 {

                public test1()
                {
                        System.out.println("call ctor");
                }

                protected void finalize()
                {
                        System.err.println("call finalize");
                }

                public static void f()
                {
                        test1 p = new test1();
                }

                public static void main(String args[])
                {
                        f();
                        System.gc();
                        System.runFinalization();
                }
        }

After the return from the f() call, there is an object instance that
can be garbage collected; there is no reference to the object we
created while inside of f().

System.gc() frees up objects and marks them as pending for
finalization to be done.  Actual finalization processing proceeds
asynchronously with the garbage collector, so to force finalization we
can call System.runFinalization().

Because of the way that finalize() methods work, you should use
caution in assuming that they can be used to reclaim valuable
resources such as UNIX file descriptors.  Also, you should insert a
line like:

        super.finalize();

at the end of a finalize() method, to call the corresponding method of
the superclass.


FREE JAVA LIBRARY

I have developed a Java library for managing collections of objects,
such as lists, stacks, sets, bitmaps, and trees.  If you are
interested in this library, please see the Web page:

        http://rmi.net/~glenm/javalib/index.html


ENUMS AND JAVA

In C++ there is a facility known as enumerations or enumerated types
that can be used to represent a set of integral values:

        enum Color {CO_R = 1, CO_G = 2, CO_B = 3};

After this declaration, Color can be used as a type (including for
function overloading purposes), and values like CO_R can be used
wherever integral constants would be used.  Type checking is done, so
that for example:

        Color c = CO_R;

        c = 37;

is invalid.

Java does not have enumerations.  One way to simulate them is simply
by defining constants in a class:

        public class Color {
                public static final byte CO_R = 1;
                public static final byte CO_G = 2;
                public static final byte CO_B = 3;
        };

public means that these values are accessible to all, static means
that they're shared across all object instances, final means that
they're immutable once set, and byte means that they're represented in
bytes in the virtual Java machine.

Once a class like this is set up, you can say things like:

        byte b = Color.CO_G;

But notice that this simulation is only a simulation.  There's nothing
to stop me from saying:

        byte b = Color.CO_R;
        b = 29;

and thereby introduce an invalid color value.  A solution to this
problem would be to define Color as a "real" class, that represents
the actual current value of an enumeration:

        public class Color {
                private byte value = 0;
                public static final byte CO_R = 1;
                public static final byte CO_G = 2;
                public static final byte CO_B = 3;
                public Color(byte b)
                {
                        if (b == CO_R || b == CO_G || b == CO_B)
                                value = b;
                        else
                                throw new IllegalArgumentException();
                }
                public byte getvalue()
                {
                        return value;
                }
        }

This approach works, but can be cumbersome to use.  However, enums,
like other language features, add to the total complexity and
implementation cost of a language, and leaving them out of Java is a
reasonable design tradeoff to make.


INTRODUCTION TO APPLET PROGRAMMING PART 3 - EVENTS

In previous issues we've talked about the basic protocols underlying
an applet and how graphical and text output is done.  With this issue
we'll start a discussion of input handling, and begin by talking about
events just a little bit.

Here is an applet that allows a user to do free drawing with the
mouse.  That is, whenever the mouse button is held down and the mouse
moved, a line will be drawn:

        import java.applet.*;
        import java.awt.*;

        public class Draw extends Applet {

                int prev_x = 0;
                int prev_y = 0;
                int color = 0;

                public boolean mouseDown(Event e, int x, int y)
                {
                        prev_x = x;
                        prev_y = y;
                        return true;
                }

                public boolean mouseDrag(Event e, int x, int y)
                {
                        Graphics g = getGra